Version Management for release 0.5 and Beyond - #2098
Conversation
|
Nightly build for this pull request:
This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build. |
I thought these shouldn't exist? Since we've already merged the fix on the pre-release, what's the use of more release versions? Should the next release after v0.5 be v0.6, I think? |
|
No. We can't guarantee that ALL bugs will be fixed before release, and it is unreasonable to try so, simply because pre-release is not a wide release. |
If we want the release to also track the bug fixes in dev, then what is the significance of pre-release? |
To provide a bug-free patched version, of course. Dev gets new features and changes that introduce new bugs, it is almost never bug-free because of that. Pre-release doesn't get new features, only fixes, so it's naturally less bugged. |
Is there any difference between this and release? There are no new features in the release, only fixes. |
Level of stability. Pre-release is "we're doing final testing to weed out bugs, polish things and prepare for the release", release is "we're confident in some level of stability". |
|
I think it's not necessary. Their functions overlap. If you want to debug on the pre-release version, then there's no need to debug on the release version. |
|
I don't understand what's the problem, we've been doing pre-release all this time with RC versions, that's the same, but just more frequent (each devbuild instead of what, 5-10 devbuilds?). You can't immediately release a stable version from a develop version without it containing a good amount of bugs, hence why pre-releases. That's common tactic in software development. |
In my understanding, when v0.5 releases the release version, v0.6 begins pre-release, which is a preparation phase. Therefore, before v0.6 completes its release, v0.5 still needs maintenance, just as the release version of v0.4 exposed issues like the construction yard not being sellable properly and the harvester failing to create voxel debris for the flying wheels when destroyed, and then v0.4.0.1 addressed these issues. It is inappropriate to solve problems by having users switch to the pre-release version of v0.5 (in the current scenario, temporarily served by the
|
DeathFishAtEase
added
the
No test needed
This comment was marked as outdated.
This comment was marked as outdated.
How about CMake :hypercarville: |
begone demon |
@copilot Split this task and provide a specific implementation path. |
|
How can I help you with this PR? |
|
Adopt a Git Flow–based model: develop for new features, release/X.Y for stabilization (only fixes and polish), and hotfix branches for critical patches to already released versions. (a proposal from a non-human mind) |
Implement the works listed by Kerbiter. |
|
A bounty of 100 CNY will be awarded to all individuals who ultimately make significant contributions (to be judged by myself) to the implementation work of this PR. |
Since it's not easy to send money between China and the rest of the world, I'll help out by covering the expense (seems to be equivalent to $15 USD?) for PayPal or intra-Ukraine transfers, so that non-Chinese contributors have some incentive too / you won't be burdened with international transfers. |
- Remove DevBuild configuration - Release configuration no longer sets IS_RELEASE_VER preprocessor directive, references across codebase changed to use RELEASE definition - Metadata is determined based on preprocessor definitions set based on compiler option BuildType (NIGHTLY, PRERELEASE & RELEASE) - Workflows updated to use the new compiler options and accomodate configuration changes
|
I updated the build configuration, metadata and workflow files.
The thing missing from the to-do list still is the automatic release / changelog generation. |
The copyright symbol was corrupted to U+FFFD when the file was re-saved as UTF-8 without a BOM. Restore it and encode the file as UTF-8 with a BOM so rc.exe decodes it correctly (it assumes ANSI without one); document the exception in .editorconfig. Assisted-by: DeepSeek V4 Flash
Re-running the release workflow appended a second copy of the changelog. Wrap it in a marker block that is stripped before re-appending, and drop the non-existent update_release_body input. Assisted-by: DeepSeek V4 Flash
General-Info referenced a 'v0.5.0.0-beta1' release that doesn't exist (releases use the short form) and claimed nightlies use a development build number that no longer applies (they share the version's savegame ID). Clarify the release vs nightly build type in copilot-instructions. Assisted-by: DeepSeek V4 Flash
Write STR_GIT_COMMIT / STR_GIT_REF / STR_GIT_DIRTY into a generated $(IntDir)Generated\Phobos.Git.h that Phobos.version.h includes, instead of passing /D defines to every translation unit. A changed commit now only rebuilds the few units that include the header (WriteOnlyWhenDifferent keeps no-op builds from churning), instead of all 223. The STR_* values are spelled out directly because rc.exe cannot stringize a file-defined string literal. Assisted-by: DeepSeek V4 Flash
Add the versioning-scheme diagram (from 0.5 onward) to the branching model section, right after the intro, with a footnote pointing to the editable Excalidraw source. Assisted-by: DeepSeek V4 Flash
…defines Include both Debug and Release Generated folders (Phobos.Git.h lands in whichever config is built; cpptools has no predefined Debug/Release variable, so list both). Add the always-present defines from Phobos.props that were missing (_WIN32_WINNT, NTDDI_VERSION, PHOBOS_DLL); keep _WINDLL since MSBuild adds it for the DLL config. DEBUG/NIGHTLY/RELEASE are config-specific and stay out. Assisted-by: DeepSeek V4 Flash
A pre-release whose own heading carries notes is now released as just those notes; an empty or missing heading falls back to the base version it leads up to, instead of appending the tagged subsection and everything below it to the base sections. Also drop the now-unused Version TBD fallback and recognize MyST colon fences alongside backtick and tilde ones. Assisted-by: DeepSeek V4 Flash
|
Contents of Automatic changelog generation probably needs testing, I can try to do that later if no one else has gotten to it by then. |
# Conflicts: # docs/Whats-New.md
…itle to the dropdown
|
@Starkku I was successful with the script already locally in my testing, haven't tried CI |
This reverts commit 494a24d.
…ding a title to the dropdown" This reverts commit 151cc4c.
Repeated sub-headings inside {dropdown}s (e.g. the many "#### Vanilla fixes:"
blocks in Whats-New.md) produce "Duplicate implicit target name" INFO/1 system
messages. Sphinx's ApplySourceWorkaround folds them into the rubric rawsource,
and the gettext builder extracts that rawsource as a bogus translatable msgid
into the .pot/.po files.
Add a local extension docs/_ext/sanitize_system_messages.py that drops
system_message nodes and repairs the polluted rawsource at doctree-read,
register it in conf.py, and regenerate the zh_CN catalogs.
Assisted-by: DeepSeek V4 Flash
Replace the regex that matched docutils' system-message render format with a format-agnostic repair: docutils prepends the node's own source path when it formats the attached message, so strip everything from that path onwards. This survives smart-quote transforms and wording changes to the message. Note: the source must be read with getattr(node, 'source') - MyST stores it as a plain attribute, not in the docutils attribute map. A structural alternative (rawsource == astext) does not work because smart quotes already curl the message's inner quotes by doctree-read. Assisted-by: DeepSeek V4 Flash
The doctree-read hook (priority 880) fixed gettext extraction but ran after the
Locale transform (priority 20), which matches rawsource against the translation
catalog - so duplicate headings inside {dropdown}s never got translated (only
the first occurrence did). Register the repair as a transform at priority 15,
after ApplySourceWorkaround (10) folds the message into rawsource and before
Locale (20).
Assisted-by: DeepSeek V4 Flash
pointing to "release model and version lifecycle" and "Migration (breaking changes)". The current format cannot be navigated correctly on ReadTheDocs.
The implementations of these attack move enhancements from Phobos-developers#1730 are problematic, so remove them before the upcoming release. Keeps AttackMove.Follow and AttackMove.IgnoreWeaponCheck, and drops the dependent mega mission fix hook (Phobos-developers#1759) that only served the removed feature.
6 participants
During several hours of communication, many details were confirmed. To avoid loss, Kerbiter suggested that I first update the document and create a PR draft.
The early blueprint of the new version management system was also mentioned in the phobos-chat channel of the C&C Mod Haven server:
@Metadorius's TODO:
Volunteers needed! this is long overdue, as is "devbuild" release, as is 0.5.